Producing Tips
Overview Cette leçon explique quelques concepts de gestion de projet, de conception et de logique de production fondamentaux et faciles à appliquer lors des différents projets qui vous seront demandés. Documents * Présentation: Production Tips and Tricks * Template Excell: Liste des tâches priorisées Pour aller plus loin Vidéos * Why DarkSouls is the Ikea of games* * Designing a game for commercial success * Technical Debt: Improviing the production pipeline * Setting (and keeping) goals * Minimum Viable Product: Scope small, start nice NOTES Conception Définir les piliers créatifs du jeu Lors de la conception d'un jeu, on a tous un peu envie de faire un jeu qui nous plait à nous, cependant cela mène souvent à un jeu décousu si il n'y a pas de vision globale. Pour éviter cela il faut définir les piliers créatifs qui constitueront l'ADN de votre jeu, votre but à atteindre, vos forces (et réciproquement, vos faiblesses).A chaque décision dans le projet, posez vous la question suivante: Est-ce que ce changement renforce les piliers créatifs de notre jeu ? Faire des choses simples mais bien L'objectifs de ces projets et de finir sur votre book, que vous en soyez fiers et que des recruteurs les consultent. Il est facile d'avoir envie de faire un jeu au mécaniques complexes ou au monde immense, mais je vous conseille de garder une seule chose en tête: Quality > Quantity. 5min de jeu fun et beau > 50min de jeu bof et fade. '''Il y a aussi beaucoup à apprendre lorsque l'on travaille sur le polish d'un jeu. Penser au ROI de chaque feature Le ROI, ou '''Return On Investment, est tout simplement la rentabilité "temps vs valeur ajoutée" de quelque chose. Lorsque vous pensez au design de votre jeu, aux décisions de direction artistique, etc... essayez de vous projeter un minimum sur le temps que cela va prendre à réaliser et comparez avec la place que prends cette feature dans votre projet. Si c'est un détail du jeu, il vaut souvent mieux partir sur des solutions simples et rapides, si c'est coeur à votre jeu, ça vaut surement le coup d'investir du temps dedans, mais pensez toujours à ce ratio temps vs valeur ajoutée au jeu. Full Production Utiliser des place-holders Les place-holders sont simplement des objets temporaires qui sont voués à être remplacés/améliorés plus tard pour obtenir une version finale. Pour une table par exemple, on va créer un nouvel objet "Table" avec un nouveau mesh 3D qui a plus ou moins les dimensions voulues, qui va permettre aux LD d'utiliser cet objet dans le monde rapidement. Ensuite, lorsque l'artiste en charge prendra le temps de livrer la version finale, toutes les tables du mondes recevront ce changement. Ils sont utiles car ils permettent notamment: * De faire en sorte d'éviter les dépendances entre les corps de métiers et permettre de paralléliser le travail * De réfléchir à chaque nouvel objet, aux choses qui vont être nécessaires et d'identifier les potentiels problèmes à l'avance * D'avoir une version jouable de A à Z du jeu rapidement Penser à la dette technique On appelle "Dette Technique", la liste des limitations ou obligations techniques du projet. Dans les fait, réfléchir à la dette technique revient surtout à être conscient des limitations que vos choix vont entraîner. Cela demande peut être difficile pour des étudiants mais je vous demande juste d'y penser lorsque les décisions ont un impact majeur sur le jeu. Savoir que si on prends cette décision, certaines portes se fermeront et que tout le monde en est conscient sur le projet est important. Exemple de limitation: Si on décide d'avoir des contrôles très complexes dans le jeu, on sera surement contraints de devoir jouer au clavier ou d'investir beaucoup pour rendre ça ergonomique à la manette. Exemple d'obligation: Si on décide que le joueur peut choisir le sexe de son personnage, il va falloir prendre en compte que cela oblige d'avoir toutes les animations, voix et modèles en version masculine et féminine. Debug Tools Pour tester l'intégration de son travail dans le jeu et il est souvent long de jouer jusqu'à l'endroit qu'il nous intéresse. Que ça soit permettre de skip des niveaux ou bien avoir un moyen de gagner autant d'or que l'on souhaite, il est souvent très utile de penser à des outils qui faciliteront le test pendant la production. Essayer de voir ce qu'il vous prends du temps à tester et penser à comment rendre le procédé plus simple. Il est aussi utile de faire une map de test parfois plutôt que des outils directement en jeu. Exemples: * Si il y a plusieurs niveau qui s’enchaînent de manière linéaire, il serait utile d'avoir une touche qui me permet de passer directement au niveau suivant * Si il y a différents types d'ennemies, il serait utile d'avoir un niveau où il est facile d'affronter chaque type d'ennemie séparément Faire tester sont jeu par d'autres personnes (et sur une build) Aussi appelés "playtests", les sessions de jeu avec des gens extérieurs à votre équipe ou votre classe vont vous permettre de prendre du recul sur l'expérience du joueur sur votre jeu. En effet, après avoir passer des heures à travailler dessus, on a tendances à avoir du mal à être objectif et à ne pas remarquer certains problèmes évident de l'extérieur. Il est recommandé de faire passer des playtests tôt dans votre production afin d'avoir le temps de d'identifier les problèmes, de réfléchir à des solutions et d'intégrer à votre jeu les changements décidés. Faire des build du jeu régulièrement Tester directement dans l'éditeur est parfait pour avancer rapidement lorsque l'on teste et que l'on itère, cependant le rendu qu'il vous est demandé en fin d'année, c'est un jeu, et pas un projet de jeu. Pour cela nous allons voir comment générer l'executable de votre jeu au cours de l'année et je vous conseille de lancer cette génération au moins une fois par semaine. Tout simplement dans le but de s'assurer qu'il n'y a pas de différences entre le moteur et le jeu final, ou bien de repérer les problèmes à l'avance (plutôt que 2 semaines avant le rendu héhé) Project Management Établir des milestones (et les prendre en compte) Il est très fréquent d'avoir beaucoup de changement au cours d'une production de jeu, que ce soit en itérant sur des idées ou pour des raisons techniques. Afin de s'assurer que malgré tout c'est aléas, le projet reste faisable dans les temps, il faut établir des dates clés associés à des objectifs à atteindre à ces dates qui serviront d'échéances intermédiaires. Ces dates, appelées "milestones", sont une occasion de prendre du recul sur l'avancé du projet et de prendre les décisions qu'il faut pour être dans les temps (souvent synonyme de cut des trucs). Les milestones communes en production sont : * First Playable Prototype (ou FPP): Le coeur de la boucle de jeu doit être présente, le jeu à cet étape sert de "proof of concept" et rien n'est final * Alpha: Tout doit être présent dans le jeu (feature, graph, ld, etc..) mais en version non finale. On doit pouvoir avoir une bonne idée du gameplay final à ce stade * Beta: Tout est présent et plus aucun place-holder ne sont dans le jeu, la grande majorité du jeu est en version finale même si quelques détails reste à perfectionner * Release/Gold/Ship: Tout est là, fini, polish, et le jeu peut sortir Définir le MVP et prioriser les tâches Le MVP, ou Minimum Viable Product, est la version fonctionnelle de votre jeu la plus simple possible. Définir le MVP consiste à faire une liste des tâches qui sont essentielles à la réalisation du jeu dans sa forme la plus basique. Une fois le MVP définit, les tâches supplémentaires qui participent à améliorer le jeu doivent être ensuite prioriser afin de définir facilement ce qui peut-être cut en cas de manque de temps. On parle souvent de "Must-Have", "Good to Have" et "Nice to Have".